In a traditional host-terminal architecture, the terminal is only responsible for displaying information to a user and receiving input from the user. The terminal does not process any information. The input information is passed to the host for processing. This places a burden on the processing capabilities of the host as well as the communication medium linking the host and terminal.
Communication from host to terminal is done by pages or screens. A page specifies what information to display and where to display it. Input data at the terminal can be displayed immediately, but only in specified input fields of a page, otherwise input is sent back to the host without displaying at the monitor.
Terminal emulation is a software package that emulates a terminal model. For example, a VT200 terminal emulation that runs on a Microsoft Windows PC is software that receives VT200 commands and transforms that into commands for Microsoft Windows PC, and sends back input data in VT200 format. The host has no knowledge that it communicates with an emulator, not a true VT200 terminal.
FIG. 1 depicts in a schematic a computer system 100 with terminal emulation as may be found in the art. Host 105 communicates with one or more terminals 115. The terminal 115 may be a computer with terminal emulation 116. The communication is controlled by host software 110. Device 125 is attached to the terminal 115 through an interface 130. Communication between the terminal 115 and the device 125 is controlled by the device driver 120.
A problem with this type of device communication system 100 is that each command to a device must be issued from the host software 110 and responded to by the terminal 115. The terminal does not process commands, or information, as a result all error correction, exception handling, and any other information processing is done by the host 105. This requirement places a processing burden on the host 105, as well as wasting communication bandwidth.
Furthermore, in order for the host software 110 to issue commands to the terminal 115 that will be recognized by the device 125, the host software 110 must be aware of the specific device commands of the device driver 120. If a device 125 is changed or upgraded, the device driver 120 on the terminal 115 must be changed, as well as the software 110 on the host 105, in order for the software to issue commands recognized by the new device driver 120.
The use of fixed input screens is problematic. This may be particularly problematic when the device 125 is an RFID reader, which may return varying amounts of information in response to a single command. Data is placed in designated input fields. If there is not enough input fields, data is discarded. If input fields are not all filled, the host 105 has no way of knowing if there is a read error or if there is not enough tags to fill the fields.
It is also difficult to fully utilize devices 125 such as RFID readers which can be both input and output depending on applications. This type of device often has a command-response type of interface, which requires a faster response rate and the ability of changing configuration parameters on-the-fly. Host-terminal architecture is not well adapted to support this type of interface because the terminal 115 does not process information locally. For writing an RFID tag, data is sent to the terminal 115, but actual writing may not take place until some kind of a trigger at the terminal 115 is activated. This arrangement is problematic. In order to notify the user that the RFID device is activated, a “trigger pulled” event has to be sent back up to the host 105. The host 105 or host software 110 then sends a write command back to the terminal 115 to tell the device 125 to start writing the data, and a command to the terminal 115 telling it to display a warning that an RFID device has been activated. The time elapsed from when the trigger is activated until action at the device 125 is actually initiated can be seconds, which is too long for this type of operation. Also, there is no mechanism for the device 125 to communicate the status of the last operation to the host 105, or the software 110 running on the host.
Another limitation is difficulty in implementing enhancements. Data coming directly from the device 125 often requires some form of editing or processing before it can be sent back to the host 105. This may be problematic if the terminal has to support multiple device drivers. If the editing is done in the device driver 120, the same code or software will have to be included in all the drivers 120. A bug fix in one driver 120 would have to be re-done again for all the drivers.
What is needed is a design for an efficient host-terminal based system such that it can utilize the computer processing of the terminal thereby reducing the processing burden on the host, as well as reducing communication bandwidth requirement.
What is further needed is a flexible device communication system such that it allows for devices to be added, or upgraded and requires no or very little changes of software on the host.